Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000092_owner-urn-ietf _Thu Nov 7 09:57:35 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27820 for urn-ietf-out; Thu, 7 Nov 1996 09:57:35 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27815 for <[e-mail]>; Thu, 7 Nov 1996 09:57:33 -0500
Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21634  (mail destined for [e-mail]); Thu, 7 Nov 96 09:57:31 -0500
Received: by seawall with  (8.6.12/) id JAA07179; Thu, 7 Nov 1996 09:57:18 -0500
Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3)
    id sma007150; Thu Nov  7 09:56:30 1996
Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail
    id <[e-mail]>; Thu, 07 Nov 96 09:57:18 EST
From: Fisher Mark <[e-mail]>
To: "[e-mail]" <[e-mail]>,
        Bob Briscoe <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [URN] Persistence as part of URN framework
Date: Thu, 07 Nov 96 09:53:00 EST
Message-Id: <[e-mail]>
Encoding: 42 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: [e-mail]
Precedence: bulk
Reply-To: Fisher Mark <[e-mail]>
Errors-To: [e-mail]

>Using DNS TTL records for this is just broken; DNS TTLs are used
>to limit caching of name->address mapping, and in the NAPTR proposal,
>they should be a fraction of the time one expects to have advance
>warning of a server relocation or mapping restructure.
>Normal TTLs are on the order of 3 days, and are usually reduced to less
>than 1 day before serious network reorganizations.

And if you are changing your resolution services faster than that, you are
changing them too fast (IMHO).  Perhaps the key idea TimBL came up with in
devising the Web was that, unlike other hypertext systems (including the
Dexter model), links could be broken, i.e. nonfunctional.  This single idea
was perhaps above all others important in spreading the Web far and wide, as
perfectly reliable systems as difficult to construct (even for an
appropriately low value of "perfect").  Under the Dexter model, an
application will die or limp on after reporting an internal error upon
encountering a broken hyperlink.  In the Web, the UA just keeps surfing on
to the next link.

All that URNs can do is assist in persistence; persistence itself must be
maintained outside the URN architecture, as persistence is ultimately a
political/economic quality, not a technical quality.  We would expect a BT
URN to persist because of our trust in BT, not because there is some
technical solution to persistence.  Persistence is assisted in URNs by the
ability to hand off resolution duties automagically to successor resolution
entities.  I would regard measures of persistence to be an optional but
necessary part of the metadata for a URN, not as mandatory metadata.  It is
quite possible that URN will see incredibly wide use, as much or more as
URLs are now ("every person a URN namespace owner").  Many of these
namespaces may just persist for a few years or months, with the owner not
caring about measures of persistence.  Persistence is ultimately up to the
creating/resolving entity(s).

Uniqueness is an easier problem than persistence, although uniqueness has a
strong political/economic component.  One can certainly imagine the case of
URNs for government materials that, after they are first created for public
consumption, are found to be embarrassing to that government and the URNs
are silently, suddenly changed to refer to much more innocuous materials.
 Uniqueness, also, is ultimately up to the creating/resolving entity.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[e-mail]                   Indianapolis, IN